Document status	35 - Reviewed

Entra ID groups overview

Purpose

This page describes how Entra ID groups are used for:

• Azure infrastructure RBAC
• EnergyConnect application roles
• Customer and Fellowmind access management

The general access model is:

User → Access group → Application role or Azure RBAC role → Application operation or Azure resource

An application role is a logical authorization role exposed by EnergyConnect, for example MeteringPointReader. A protected API operation requires one or more application roles. Access to the operation is therefore an effective permission provided by the role; it is not a separate Entra ID group or permission object.

Provisioning

Infrastructure groups, technical application groups, customer access groups and role assignments are provisioned by the Bicep platform prerequisites deployment. Entitlement Management access packages and their assignment policies are managed by the governance scripts in Infrastructure/Scripts/entra-id.

Do not create Bicep-managed groups manually in the portal. Bicep assigns stable uniqueName values so subsequent deployments reuse the groups instead of creating duplicates.

Infrastructure access

Naming convention

ec-{env}-{customer}-infra-{role}

Where:

• env is the deployed environment, for example test, staging or prod
• customer is the customer short code, for example ne
• role is reader, contributor, owner or vm-admin

Effective Azure access

Infrastructure groups receive Azure RBAC assignments at subscription scope.

Group suffix	Azure roles and access
infra-reader	Reader, Virtual Machine User Login, App Configuration Data Reader, Container Apps Operator, and the custom Start and Stop Virtual Machines role where available
infra-contributor	Contributor and Storage Blob Data Contributor
infra-owner	Owner and Storage Blob Data Contributor
infra-vm-admin	Virtual Machine Administrator Login and Reader

The custom start/restart VM role is not assigned in tenants where its management-group role definition is unavailable.

Infrastructure access flow

• Reader access is the always-active baseline. The tenant's central EnergyConnect reader group is nested into each environment's infra-reader group.
• Self-service elevated access is exposed through consolidated Contributor access packages.
• A Contributor package bundles both infra-contributor and infra-vm-admin for the relevant environments.
• These group assignments are PIM-eligible. After approval, the user activates access with MFA and justification for a time-limited period.
• infra-owner is intentionally not exposed through self-service access packages because the role is too broad.
• Non-production access is available through one package spanning all customers' non-production environments. Production access is separated by customer or brand.

Infrastructure access is Fellowmind-internal and managed by Fellowmind. Customers do not manage Azure infrastructure access.

Application authorization

Application roles

EnergyConnect exposes these roles through each environment's Client.Auth service principal:

Role value	Display name	Purpose
MeteringPointReader	Målepunkt Læser	Read metering point data
MeteringPointWriter	Målepunkt Redaktør	Create and update metering point data
ConnectionPointReader	Tilslutningspunkt Læser	Read connection point data
ConnectionPointWriter	Tilslutningspunkt Redaktør	Create and update connection point data
AggregatedDataReader	Afstemning Læser	Read reconciliation data
VEEReader	VEE Læser	Read VEE data
VEEWriter	VEE Redaktør	Create and update VEE data
ChargeInformationReader	Priselementer Læser	Read charge information
ChargeInformationWriter	Priselementer Redaktør	Create and update charge information
TopologyReader	Topologi Læser	Read topology data
TopologyWriter	Topologi Redaktør	Create and update topology data
Hangfire	Hangfire	Access the Hangfire dashboard

The role value is the technical value used by API authorization. The display name is the user-facing name shown in Entra ID.

Example:

MeteringPointReader → GET getByConnectionPointId

The operation is authorized with MeteringPointReader; it does not have its own Entra ID group or standalone permission object.

Technical environment groups

The platform still provisions environment-specific technical application groups and assigns app roles to them. They are currently used by Fellowmind access packages and are therefore not legacy at present.

Customer users must not be added directly to these technical groups. Customer membership is managed through the environment-independent customer access groups below.

Removing the technical groups requires a separate infrastructure change after all Fellowmind access packages and other dependencies have been migrated.

Customer application access

Customer access groups

Each hosted customer has three environment-independent access groups. Service Desk adds customer users to the appropriate group.

Access group	Access level	Effective application roles
App - {Customer} - All Environments - Læser	Læser	ConnectionPointReader, MeteringPointReader, TopologyReader
App - {Customer} - All Environments - Slutbruger	Slutbruger	MeteringPointWriter, AggregatedDataReader, ConnectionPointReader, ConnectionPointWriter, VEEReader, ChargeInformationReader, MeteringPointReader, TopologyReader
App - {Customer} - All Environments - Superbruger	Superbruger	ChargeInformationWriter, ChargeInformationReader, VEEWriter, VEEReader, MeteringPointWriter, MeteringPointReader, AggregatedDataReader, ConnectionPointReader, ConnectionPointWriter, TopologyReader, TopologyWriter

Membership is environment-independent, while the groups receive the listed app roles directly on each of the customer's deployed Client.Auth service principals. A customer user therefore receives the same access level in all environments for that customer.

The customer access groups are deliberately not nested in the technical environment groups. Entra ID does not issue app roles through nested group membership reliably, so nesting would not grant the required roles.

Dinel is excluded from this process because it is hosted in its own AURA tenant. Access is managed according to that tenant's deployment and operating model.

Customer access flow

1. The customer requests the required access level through the agreed service process.
2. Fellowmind Service Desk invites the user to the hosting tenant when required.
3. Service Desk adds the user directly to the appropriate customer access group.
4. The group provides app roles in each of the customer's deployed environments.
5. EnergyConnect authorizes each request from the app roles in the user's token.

Superuser or project-lead access requires the applicable approval before membership is granted.

Fellowmind application access

Fellowmind-internal application access continues to use Entitlement Management access packages backed by the technical environment groups:

Access package	Scope	Effective access
App - All Customers - Non-Prod - Developer	All customers' non-production environments	Administrator application roles and Hangfire
App - All Customers - Non-Prod - MAS / ITOC / CIS	All customers' non-production environments	System-reader application roles and Hangfire
App - {Brand} - Prod - Fellowmind adgang	The brand's production environment or environments	System-reader application roles and Hangfire

Application package membership is active rather than PIM-eligible and is time-limited according to the package assignment policy.

Responsibilities

• Fellowmind Service Desk: manage customer access-group membership for customers hosted in the Fellowmind tenant.
• Customer administrators: manage access according to the agreed operating model when the solution is hosted in the customer's tenant.
• Fellowmind access-package approvers: approve Fellowmind infrastructure and application access requests.
• EnergyConnect platform deployment: create managed groups and assign Azure RBAC and application roles.
• EnergyConnect API: enforce application roles on protected controllers and operations.